2025-05-25 Eignet sich 1fichier.com als Backupspeicher?

1fichier Logo

Kurz und knapp: Ne, leider nicht. Möchte trotzdem meine Erfahrungen teilen. Insbesondere die Lösung auf ein paar Probleme.

Hab mich neulich nach günstigen Onlinespeichern zur externen Datensicherung umgesehen. Würde gerne um die 8TB speichern wollen. Der Speicher muss entweder direkt ⎇BorgBackup oder von ⎇Rclone unterstützt werden. Dabei viel mir ein Angebot des französischen Filesharing-Anbieters ⎇1fichier.com auf. Zwar reden sie etwas unseriös von "Unlimited hot storage", das wird aber relativiert durch realistische Speicherangaben für sogenanntes "Cold Storage". In den kalten Speicher werden wohl die Daten verschoben, die eine gewisse Zeit lang nicht heruntergeladen wurden. Wie das im Detail funktioniert und wie sich das auf den Backupprozess ausgewirkt hätte, kann ich leider nicht sagen, da ich nicht solange bei 1fichier.com war, das irgendwas verschoben worden wäre.

1fichier Angebot
Um Ostern hatte der Anbieter Sonderangebote die sehr attraktiv waren. Beinahe hätte ich auch zugeschlagen, denkend das man für den Preis nicht viel falsch machen kann. Hab mich dann aber doch zurückgehalten und erst mal einen Testmonat raus gelassen. (Die kostenlosen Konten geben einem keinen API-Key, welcher für Rclone benötigt wird.)

Wie auf den Speicher von 1fichier.com zugreifen?

Wird von Rclone unterstützt. Kann also einfach gemountet werden.
# rclone --version
rclone v1.60.1-DEV
- os/version: ubuntu 24.04 (64 bit)
- os/kernel: 6.8.0-60-generic (x86_64)
- os/type: linux
- os/arch: amd64
- go/version: go1.22.2
- go/linking: dynamic
- go/tags: none

# rclone config
> n
name> fichier
Storage> fichier
api_key> abcd

# mkdir ~/fichier
# rclone mount fichier: ~/fichier/ --no-modtime --vfs-cache-mode full --links
Ich geb gerne df ein um zu schauen ob der Mount steht, nicht um zu ermitteln wie viel Speicher verbraucht wurde. Denn das wird nicht unterstützt. Ich erwähne das deshalb, weil df manchmal länger braucht und Rclone dann das hier ausgibt:

ERROR : 1Fichier root '': Statfs failed: failed to read user info: HTTP error 403 (403 Forbidden) returned body: "{\"message\":\"Flood detected: IP Locked #39\",\"status\":\"KO\"}"

Obwohl da steht “IP Locked” hab ich nie festgestellt das man wirklich blockiert ist.

Erste Probleme

Der erste Lauf von borg brachte sofort Problem.

ERROR : L1/test/lock.exclusive/L1@258168401705282.58803-0: Failed to copy: couldn't list files: HTTP error 404 (404 Not Found) returned body: "{\"message\":\"No such resource #334\",\"status\":\"KO\"}"
ERROR : L1/test/lock.exclusive/L1@258168401705282.58803-0: vfs cache: failed to upload try #1, will retry in 10s: vfs cache: failed to transfer file from cache to remote: couldn't list files: HTTP error 404 (404 Not Found) returned body: "{\"message\":\"No such resource #334\",\"status\":\"KO\"}"
ERROR : L1/test/lock.exclusive/L1@258168401705282.58803-0: Failed to copy: can't upload empty files to this remote

Borg erzeugt leere lock-Files. Leere Dateien werden von 1fichier nicht unterstützt!

# touch L1/test
ERROR : L1/test: Failed to copy: can't upload empty files to this remote
ERROR : L1/test: vfs cache: failed to upload try #1, will retry in 10s: vfs cache: failed to transfer file from cache to remote: can't upload empty files to this remote

Außer der Lock-Datei erzeugt Borg keine weiteren leeren Dateien. Man könnte also versuchen darüber hinweg zu sehen. Dann wird es später aber komplizierter zu ermitteln, ob alles erfolgreich hochgeladen wurde. Denn der Cache ist penibel und versucht alle 10 Sekunden die Datei erneut hochzuladen. Selbst dann, wenn die Datei schon wieder gelöscht wurde! Man bekommt das nur weg, wenn man den Cache löscht.
Die Lösung ist eine weitere Schicht Rclone. ⎇rclone crypt um genau zu sein. Dies fügt jeder Datei einen ⎇Header hinzu. Was ein leere Datei mindestens ein paar Byte groß macht.
# rclone config
> n
name> fichierEnc
Storage> crypt
remote> fichier:L1Enc
filename_encryption> obfuscate
directory_name_encryption> true
Option password: g 1024
Option password2: g 1024
Warum bei filename_encryption nur obfuscate? Jetzt wo Rclone die Verschlüsselung macht, war zu ermitteln ob nicht gleich ganz auf Borg verzichtet werden kann. Und ich kenne von EncFS das die Länge von Dateinamen sehr schnell zum Problem wird. Für Borg sind die kürzeren Dateinamen kein Problem und man kann auch standard nehmen.

# rclone mount fichierEnc: ~/fichier --no-modtime --vfs-cache-mode full --links
# mkdir ~/fichier/Foo
# fusermount -u /root/fichier

# rclone sync /home/foo/ fichierEnc:Foo --dry-run
# rclone sync /home/foo/ fichierEnc:Foo --progress --transfers=2 --filter "- /.cache/**" --filter "- /.local/**" --filter "- **/.Trash-*/**" --filter "- .sync_*.db*" --filter "- *.txt.kate-swp"

Selbst wenn man auf alle sonstigen Vorteile, die Borg mit sich bringt, verzichten kann, wird schnell klar, mit rclone sync wird das nichts. Entweder fängt 1fichier an zu drosseln oder deren System bricht ein. Fakt ist, speziell wenn viele kleine Dateien erzeugt werden sollen, da vergehen stellenweise 30 Sekunden ohne Upload, bis die nächste Datei erzeugt wird. Borg macht aus Millionen Dateien, wenige Zehntausende Archivdateien. Also zurück zu rclone mount und Borg.

Der ausgewachsene rclone mount Befehl, mit dem ich bis zum Schluss gearbeitet habe:

# rclone mount fichierEnc: ~/fichier --no-modtime --vfs-cache-mode full --dir-cache-time 5h --vfs-cache-max-age 5h --links --transfers=2 --rc --log-file ~/fichier-rclone.log --log-format=date,time,pid &

Die --rc Option wird später benötigt um zu ermitteln ob die Uploads abgeschlossen sind. Ich verwende ein & obwohl es ein --daemon Parameter gibt, da sich rc und daemon nicht mischen lassen. (Vermutlich ein Bug.)
Mit --rc und --daemon kommt folgender Fehler:

Failed to start remote control: start server failed: listen tcp 127.0.0.1:5572: bind: address already in use
Fatal error: mount not ready


# export BORG_PASSPHRASE=1234
# export BORG_CACHE_DIR=/root/.cache/borg/
# borg init -e repokey-blake2 ~/fichier/Foo
# borg key export ~/fichier/Foo/ hostname.Foo.borgkey # zum Passwortsafe
# borg create \
--list \
--stats \
--progress \
--compression zstd \
--exclude '/home/foo/.Trash-*/' \
--exclude '/home/foo/.cache/' \
--exclude '.sync_*' \
--exclude '*.txt.kate-swp' \
/root/fichier/Foo::{hostname}-Schrank-{now:%Y-%m-%dT%H:%M:%S} /home/foo

So jetzt die nächsten Probleme

Was gesichert werden soll ist "klein", borg create läuft ohne Fehler durch.
Jedes zweite oder dritte mal bleibt lock.exclusive liegen. Zwar erkennt brog beim nächsten Lauf, das die Locks nicht mehr gültig sind und entfernt sie, aber die Dateien sind trotzdem unnötig. Darum hab ich nach borg create immer

sleep 35 && rm -rf /root/fichier/Foo/lock.exclusive/

stehen.

Aber viel Problematischer ist, führt man umount oder fusermount -u aus (letzteres ist der passendere Befehl, der sicherstellt das sich rclone beendet), wird nicht auf noch laufende Uploads gewartet. Borg arbeitet so schnell, was der Cache auf der lokalen Partition eben her gibt. rclone mount kann, mit 1fichier jedenfalls, nicht ohne Cache betrieben werden. Sprich, nur weil brog lokal fertig ist, heißt es nicht das die Daten vollständig auch online gespeichert sind!
Primitiv kann man mit du -sh ~/.cache/rclone sehen wie viel Daten ungefähr noch ausstehen. Aber jetzt kommt die --rc Option ins Spiel.
Mit rclone rc vfs/stats erhält man Infos, im JSON-Format, zum Status des Cache.
# rclone rc vfs/stats
{
  "diskCache": {
    "bytesUsed": 0,
    "erroredFiles": 0,
    "files": 0,
    "hashType": 4,
    "outOfSpace": false,
    "path": "/root/.cache/rclone/vfs/fichier",
    "pathMeta": "/root/.cache/rclone/vfsMeta/fichier",
    "uploadsInProgress": 0,
    "uploadsQueued": 0
  },
uploadsinProgress und uploadsQueued sagen einem ob noch Daten hochgeladen werden müssen. Diese Schleife hängt so lange, bis alle Uploads vollendet sind:

while [[ $(rclone rc vfs/stats | jq '.diskCache | [.uploadsInProgress, .uploadsQueued] | add') -gt 0 ]]
do
  sleep 15
done

Geklaut von https://github.com/rclone/rclone/issues/1909#issuecomment-1557291969 Anschließend kann ein unmount ausgeführt werden.

Leider gibt es auch hier gelegentlich wieder Probleme. Manchmal reagiert rclone rc vfs/stats eine Zeit mit folgender Meldung:

Failed to rc: connection failed: Post "http://localhost:5572/vfs/stats": net/http: timeout awaiting response headers

Ich vermute das hängt mit der Anzahl der auf 1fichier abgelegten Dateien zusammen. Es vergingen bei 2TB gespeicherten Daten teilweise 20 Minuten, bis rclone rc vfs/stats mit Daten antwortete. Weswegen vor der ersten while Schleife noch diese nötig ist:

while rclone rc vfs/stats > /dev/null 2>&1; rcexit=$?; [[ $rcexit -ne 0 ]]
do
  sleep 15
done

(Wenn es einmal läuft, dann läuft es. Nach dieser Schleife kann also die Erste laufen, ohne das nochmal auf Timeouts geprüft werden muss.)
BTW: Ein vorzeitiger unmount bedeutet keinen Datenverlust. Sie bleiben, unabhängig von max-age-Werten, im Cache erhalten und der Upload läuft nach einem rclone mount weiter. Diesmal wird aber gewartet bis der Upload vollständig ist, bevor der mount als vollzogen gilt.

Inititale Sicherung ist größer als der Cache verkraften kann

Wie schon geschrieben, werden Daten ohne Berücksichtigung einer Internet-Upload-Geschwindigkeit, zunächst auf dem lokalen Cache abgelegt. Auch die Option --vfs-cache-max-size schützt einen nicht davor, das für den Upload die ganze Partition vollgeschrieben wird. Wenn es knallt erhält man endlos diese Meldungen:

NOTICE: vfs cache: in KickCleaner, ready to kick cleaner
ERROR : Foo/nonce-tw16sq4g.tmp: vfs cache: failed to open item: vfs cache item: create cache file failed: vfs cache item: _save failed: vfs cache item: failed to encode metadata: write /root/.cache/rclone/vfsMeta/fichierEnc/Foo/nonce-tw16sq4g.tmp: no space left on device

Noch BEVOR es knallt muss borg per ⎇SIGINT beendet werden. Dann muss gewartet werden bis die Uploads vollzogen worden sind. (Per iftop und watch -n 30 "du -sh ~/.cache/rclone && df -h /" kann dabei zugesehen werden.) watch -n 30 du -sh .cache/rclone
Borg kommt super mit Abbrüchen zurecht. Man startet also den nächsten Lauf. Was schon im Archiv liegt wird übersprungen, landet also nicht nochmal im Cache. Das muss man dann evtl. mehrfach wiederholen, bis Borg zu Ende laufen konnte. Zukünftig muss der Cache nur noch soviel Daten tragen können, wie Täglich geändert werden. Aber bekloppt ist das so halt schon!
Der einzige Workaround der mir dazu einfallen würde ist, mit Borg nicht direkt auf die 1fichier Partition zu schreiben, sondern einen Umweg über ssh localhost zu machen. Dabei mit dem --upload-ratelimit Parameter einen realistischen Wert setzten. Rclone muss die Daten schneller online an 1fichier wegbekommen als Borg sie reinhaut.

Ich kam nicht soweit den Workaround zu konkretisieren. Als ca. 2TB archiviert waren, musste ich feststellen dass eine Borg-Archivdatei von 1fichier nicht gefressen wird:

ERROR : Foo/data/3/3289: Failed to copy: upload response not found
ERROR : Foo/data/3/3289: vfs cache: failed to upload try #12, will retry in 5m0s: vfs cache: failed to transfer file from cache to remote: upload response not found

(Das wiederholt sich bis in alle Ewigkeit.)
Da kann man dann nichts machen. Das ist eine Hash-Kollision, ein False Positive ihres "Anti-Virus".
https://github.com/rclone/rclone/issues/5152#issuecomment-806180778
Da bin ich dann doch froh das jetzt, gleich mit dem ersten Archiv, abbekommen zu haben. Wäre viel schlimmer gewesen, wäre ich auf Jahre in Vorkasse gegangen und es hätte ein Bestandsarchiv getroffen. (Klar, man könnte es mit einem neuen Verschlüsselungskey nochmal versuchen. Aber jedes mal bei dem Fehler dann mehrere TB hochladen ist etwas mühselig.)

⍈Homepage

#